home *** CD-ROM | disk | FTP | other *** search
- Path: locutus.rchland.ibm.com!usenet
- From: pstaite@vnet.ibm.com
- Newsgroups: comp.lang.c++
- Subject: Re: Passing C++ member functions to Xview notifier functions.
- Date: 5 Jan 1996 15:16:54 GMT
- Organization: IBM OS/2 Device Driver Development Rochester, MN
- Message-ID: <4cjfd6$16vn@locutus.rchland.ibm.com>
- References: <4chhsn$sim@msunews.cl.msu.edu>
- Reply-To: pstaite@vnet.ibm.com
- NNTP-Posting-Host: warpone.rchland.ibm.com
- X-Newsreader: IBM NewsReader/2 v1.2
-
- In <4chhsn$sim@msunews.cl.msu.edu>, Robert Foster <rkf> writes:
- >Greetings,
- >
- >I am using C++ classes in an Xview based program on a Sun/Solaris platform.
- >
- >When I try to do the following within a class member function...
- >
- >notify_set_input_func( client1, Pipe::read_from, pipe_in_out[1][0] ) ;
- >
- >...the compiler complains about the Pipe::read_from in the following way...
-
- Next *time* spare our *time* and read the FAQ first:
-
- ==============================================================================
- SECTION 18: Pointers to member functions
- ==============================================================================
-
- Q111: Is the type of "ptr-to-member-fn" different from "ptr-to-fn"?
-
- Yep.
-
- Consider the following function:
-
- int f(char a, float b);
-
- If this is an ordinary function, its type is: int (*) (char,float);
- If this is a method of class Fred, its type is: int (Fred::*)(char,float);
-
- ==============================================================================
-
- Q112: How do I pass a ptr to member fn to a signal handler, X event callback,
- etc?
-
- Don't.
-
- Because a member function is meaningless without an object to invoke it on, you
- can't do this directly (if The X Windows System was rewritten in C++, it would
- probably pass references to OBJECTS around, not just pointers to fns; naturally
- the objects would embody the required function and probably a whole lot more).
-
- As a patch for existing software, use a top-level (non-member) function as a
- wrapper which takes an object obtained through some other technique (held in a
- global, perhaps). The top-level function would apply the desired member
- function against the global object.
-
- E.g., suppose you want to call Fred::memfn() on interrupt:
-
- class Fred {
- public:
- void memfn();
- static void staticmemfn(); //a static member fn can handle it
- //...
- };
-
- //wrapper fn remembers the object on which to invoke memfn in a global:
- Fred* object_which_will_handle_signal;
- void Fred_memfn_wrapper() { object_which_will_handle_signal->memfn(); }
-
- main()
- {
- /* signal(SIGINT, Fred::memfn); */ //Can NOT do this
- signal(SIGINT, Fred_memfn_wrapper); //Ok
- signal(SIGINT, Fred::staticmemfn); //Also Ok
- }
-
- Note: static member functions do not require an actual object to be invoked, so
- ptrs-to-static-member-fns are type compatible with regular ptrs-to-fns (see ARM
- ["Annotated Reference Manual"] p.25, 158).
-
- ==============================================================================
-
- Q113: Why do I keep getting compile errors (type mismatch) when I try to use a
- member function as an interrupt service routine?
-
- This is a special case of the previous two questions, therefore read the
- previous two answers first.
-
- Non-static member functions have a hidden parameter that corresponds to the
- 'this' pointer. The 'this' pointer points to the instance data for the
- object. The interrupt hardware/firmware in the system is not capable of
- providing the 'this' pointer argument. You must use "normal" functions (non
- class members) or static member functions as interrupt service routines.
-
- One possible solution is to use a static member as the interrupt service
- routine and have that function look somewhere to find the instance/member pair
- that should be called on interrupt. Thus the effect is that a normal method
- is invoked on an interrupt, but for technical reasons you need to call an
- intermediate function first.
-
- ==============================================================================
-
-
-
- Phil Staite, team OS/2
- internet: pstaite@vnet.ibm.com internal: pstaite@rchland
-
-